Performance Evaluation Hong Kong Vps Speed Comparison Between Native Ip And Virtual Shared Ip

the goal of this article is to use reproducible steps to compare the speed difference between "hong kong vps using native ip (public ip/independent public ip)" and "using virtual shared ip (nat/shared public ip)" under real network conditions. the general idea is: under the same vps specifications and the same software configuration, conduct multi-dimensional tests (bandwidth, delay, packet loss, concurrent http downloads) on the two types of ips, and measure and compare the statistical data multiple times.

steps: 1) select two hong kong vps instances with the same specifications (cpu, memory, disk, computer room location, and network billing model). 2) one device must be assigned a native public ip; if the other device cannot directly obtain a "shared ip", it can apply for nat/shared public ip from the supplier or use the "virtual ip" product provided by it. 3) unify the system (ubuntu 20.04/22.04 recommended) and close redundant services.

confirmation method: log in to the vps control panel to view the ip type label; use the command in the system to view the public ip (curl -s https://ipinfo.io/ip). if the supplier description is "nat/shared ip" or ip pool, it is a shared ip. if you can purchase "independent public ip/elastic ip", it will be a native ip.

operation steps: 1) update the system sudo apt update && sudo apt upgrade -y. 2) unify network configuration: turn off unnecessary firewalls (sudo ufw disable) or open the same port on both machines for testing. 3) unify the mtu (check ip link show; modify sudo ip link set dev eth0 mtu 1500). 4) disable consistency during ipv6 testing (sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1).

required installation: iperf3 (bandwidth and delay), mtr/traceroute (routing and packet loss analysis), ping (delay), curl/wget (download rate), wrk or ab (concurrent http pressure). installation command example: sudo apt install -y iperf3 mtr traceroute curl wget apache2-utils build-essential libssl-dev && sudo apt install -y wrk (if the warehouse does not have wrk, you can compile it from the source code).

detailed steps: 1) run iperf3 -s on the test server. 2) run iperf3 -c <test target ip> -t 60 -p 4 (-t time, -p concurrent streams) on the client (external test point or another vps). 3) it is recommended to run tcp and udp separately: udp uses -u and -b to specify the bandwidth limit (for example -u -b 100m). 4) run each configuration at least 5 times and record the average value and maximum/minimum.

steps: 1) deploy a simple http service on the target vps (sudo apt install -y nginx; place a static 1gb file in /var/www/html/largefile.bin). 2) use wrk to make concurrent requests: wrk -t2 -c100 -d30 http:// /largefile.bin (-t threads, -c concurrent connections). 3) use curl or wget download to measure the actual download rate: wget -o /dev/null http:// /largefile.bin and record the average speed. 4) test multiple times and repeat over different time periods.

steps: 1) basic delay: ping -c 100 , record the average (avg), minimum (min), and maximum (max). 2) routing and packet loss: mtr -r -c 100 , pay attention to the packet loss column and the delay of each hop. 3) analyze whether packet loss occurs on the local to hk link or the provider edge. note that nat/edge overload common to shared ips will increase packet loss.

details: 1) do not run large traffic on two vps at the same time to avoid mutual interference. 2) run once during off-peak and peak hours (for example, utc 02:00 and 12:00). 3) take the median of at least 5 times for each test; retain the original output log (redirect to file). 4) if possible, conduct pull tests on the two ips from third-party nodes (such as home broadband, foreign vps) to simulate real user experience.

recording method: create csv columns: time, test type, ip type, bandwidth peak, average delay, packet loss rate, number of successful concurrent requests, and remarks. analysis: compare average bandwidth (mbps), latency (ms) and packet loss rate; focus on p95/p99 latency and success rate during concurrency. if the shared ip performs significantly worse than the native ip under concurrent downloads or udp, it means that nat or shared bandwidth restrictions have a greater impact.

suggestions: 1) if you find mtu problems, adjust the mtu to a lower value (for example, 1460) to test whether packet loss is improved. 2) check tcp window and congestion (sysctl net.core.rmem_max, etc.). 3) confirm with the supplier whether the nat device has connection restrictions or port reuse. 4) if there is frequent packet loss or high latency and the business is sensitive, give priority to native public ip or a better bandwidth guarantee solution.

example command: sudo apt update && sudo apt install -y iperf3 mtr wrk curl wget
on the server: iperf3 -s > /root/iperf_server.log 2>&1 &
client tcp: iperf3 -c -t 60 -p 4 > iperf_tcp_client.log
client udp: iperf3 -c -u -b 100m -t 30 >iperf_udp_client.log
concurrent http: wrk -t2 -c100 -d30 http:// /largefile.bin > wrk.log

conclusion: generally, native ip is better than shared ip in terms of latency, packet loss and concurrent throughput, especially for high concurrency and udp applications. however, shared ip has low cost and fast deployment, and is suitable for non-real-time or low-traffic services. the final choice should be based on test data, business needs, and budget tradeoffs.

q1: what is the general difference in latency and bandwidth between native ip and virtual shared ip?

a1: it depends on the provider and network congestion, but the common situation is that the native ip has lower latency, smaller packet loss rate, and more stable bandwidth in high concurrency or udp scenarios; the shared ip may experience a rate drop or the connection is speed-limited during peak times. the difference can be quantified through multiple tests of iperf3 and wrk above (for example, the average difference can range from a few mbps to dozens of mbps).

q2: how to ensure that the data is reliable and not affected by nat or firewall during testing?

a2: ensure that the configurations of both parties are consistent: turn off or unify firewall rules, set the same mtu, disable ipv6, test multiple times within the same time period, and test from multiple different sources (third-party nodes) to confirm whether the problem is caused by nat/edge devices. in addition, keep complete logs to facilitate communication with suppliers.

q3: how to confirm that you are getting a native public ip when purchasing a hong kong vps?

a3: before purchasing, ask the supplier whether it provides "independent public ip/elastic ip/native ip" and check whether the control panel indicates "public ip/independent ip". after purchasing, you can check the ip and provider information through curl -s https://ipinfo.io/json. if the provider states that the ip belongs to "shared/cgnat/private pool", it is not a native public network ip.